Sourced from regex's changelog.

1.11.3 (2025-09-25)

This is a small patch release with an improvement in memory usage in some cases.

Improvements:

• [BUG #1297](rust-lang/regex#1297): Improve memory usage by trimming excess memory capacity in some spots.

• ef1c2c3 1.11.3
• ad5cd6c deps: bump regex-automata
• ee69d9e changelog: 1.11.3
• 159fa3e regex-automata-0.4.11
• 02a62ba automata: call Vec::shrink_to_fit in a few strategic places
• a76e0a0 cargo: exclude tests/fuzz from the package
• 19172cc style: inline formatting arguments
• 2695e29 ci: fix cross testing
• See full diff in compare view

Sourced from sentry's releases.

0.43.0

Breaking changes

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian
  • The tracing integration now uses the tracing span name as the Sentry span name by default.
  • Before this change, the span name would be set based on the tracing span target (<module>::<function> when using the tracing::instrument macro).
  • The tracing integration now uses <span target>::<span name> as the default Sentry span op (i.e. <module>::<function> when using tracing::instrument).
  • Before this change, the span op would be set based on the tracing span name.
  • Read below to learn how to customize the span name and op.
  • When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
• ref(tracing): use standard code attributes (#899) by @​lcian
  • Logs now carry the attributes code.module.name, code.file.path and code.line.number standardized in OTEL to surface the respective information, in contrast with the previously sent tracing.module_path, tracing.file and tracing.line.
• fix(actix): capture only server errors (#877) by @​lcian
  • The Actix integration now properly honors the capture_server_errors option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).
  • Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
  • With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
  • There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
• fix: send trace origin correctly (#906) by @​lcian
  • TraceContext now has an additional field origin, used to report which integration created a transaction.

Behavioral changes

• feat(tracing): send both breadcrumbs and logs by default (#878) by @​lcian
  • If the logs feature flag is enabled, and enable_logs: true is set on your client options, the default Sentry tracing layer now sends logs for all events at or above INFO.

Features

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian

  • Additional special fields have been added that allow overriding certain data on the Sentry span:
    • sentry.op: override the Sentry span op.
    • sentry.name: override the Sentry span name.
    • sentry.trace: given a string matching a valid sentry-trace header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid sentry-trace header or a trace is already started, this value is ignored.
  • sentry.op and sentry.name can also be applied retroactively by declaring fields with value tracing::field::Empty and then recorded using tracing::Span::record.
  • Example usage:

    #[tracing::instrument(skip_all, fields(
        sentry.op = "http.server",
        sentry.name = "GET /payments",
        sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()),
    ))]
    async fn handle_request(headers: std::collections::HashMap<String, String>) {
        // ...
    }

  • Additional attributes are sent along with each span by default:
    • sentry.tracing.target: corresponds to the tracing span's metadata.target()
    • code.module.name, code.file.path, code.line.number

• feat(core): add Response context (#874) by @​lcian

  • The Response context can now be attached to events, to include information about HTTP responses such as headers, cookies and status code.

... (truncated)

Sourced from sentry's changelog.

0.43.0

Breaking changes

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian
  • The tracing integration now uses the tracing span name as the Sentry span name by default.
  • Before this change, the span name would be set based on the tracing span target (<module>::<function> when using the tracing::instrument macro).
  • The tracing integration now uses <span target>::<span name> as the default Sentry span op (i.e. <module>::<function> when using tracing::instrument).
  • Before this change, the span op would be set based on the tracing span name.
  • Read below to learn how to customize the span name and op.
  • When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
• ref(tracing): use standard code attributes (#899) by @​lcian
  • Logs now carry the attributes code.module.name, code.file.path and code.line.number standardized in OTEL to surface the respective information, in contrast with the previously sent tracing.module_path, tracing.file and tracing.line.
• fix(actix): capture only server errors (#877) by @​lcian
  • The Actix integration now properly honors the capture_server_errors option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).
  • Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
  • With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
  • There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
• fix: send trace origin correctly (#906) by @​lcian
  • TraceContext now has an additional field origin, used to report which integration created a transaction.

Behavioral changes

• feat(tracing): send both breadcrumbs and logs by default (#878) by @​lcian
  • If the logs feature flag is enabled, and enable_logs: true is set on your client options, the default Sentry tracing layer now sends logs for all events at or above INFO.

Features

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian

  • Additional special fields have been added that allow overriding certain data on the Sentry span:
    • sentry.op: override the Sentry span op.
    • sentry.name: override the Sentry span name.
    • sentry.trace: given a string matching a valid sentry-trace header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid sentry-trace header or a trace is already started, this value is ignored.
  • sentry.op and sentry.name can also be applied retroactively by declaring fields with value tracing::field::Empty and then recorded using tracing::Span::record.
  • Example usage:

    #[tracing::instrument(skip_all, fields(
        sentry.op = "http.server",
        sentry.name = "GET /payments",
        sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()),
    ))]
    async fn handle_request(headers: std::collections::HashMap<String, String>) {
        // ...
    }

  • Additional attributes are sent along with each span by default:
    • sentry.tracing.target: corresponds to the tracing span's metadata.target()
    • code.module.name, code.file.path, code.line.number

• feat(core): add Response context (#874) by @​lcian

... (truncated)

• b08b24a release: 0.43.0
• 1c08ca8 ref(tracing): keep old span name as op instead of default (#905)
• 75aff83 fix(tracing): skip default span attributes when propagating to event (#904)
• 6b61b31 fix: send trace origin correctly (#906)
• 75a8c03 ref(tracing): use standard code attributes (#899)
• bbd667a meta: add pull request template (#898)
• 5c8ab31 ref(tracing): rework tracing to Sentry span name/op conversion (#887)
• 045c2e2 feat(tracing): send both breadcrumbs and logs by default (#878)
• a5932c0 fix(transport): add rate limit for logs (#894)
• 280dab9 build(deps): bump tracing-subscriber from 0.3.19 to 0.3.20 (#891)
• Additional commits viewable in compare view

Sourced from sentry-actix's releases.

0.43.0

Breaking changes

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian
  • The tracing integration now uses the tracing span name as the Sentry span name by default.
  • Before this change, the span name would be set based on the tracing span target (<module>::<function> when using the tracing::instrument macro).
  • The tracing integration now uses <span target>::<span name> as the default Sentry span op (i.e. <module>::<function> when using tracing::instrument).
  • Before this change, the span op would be set based on the tracing span name.
  • Read below to learn how to customize the span name and op.
  • When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
• ref(tracing): use standard code attributes (#899) by @​lcian
  • Logs now carry the attributes code.module.name, code.file.path and code.line.number standardized in OTEL to surface the respective information, in contrast with the previously sent tracing.module_path, tracing.file and tracing.line.
• fix(actix): capture only server errors (#877) by @​lcian
  • The Actix integration now properly honors the capture_server_errors option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).
  • Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
  • With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
  • There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
• fix: send trace origin correctly (#906) by @​lcian
  • TraceContext now has an additional field origin, used to report which integration created a transaction.

Behavioral changes

• feat(tracing): send both breadcrumbs and logs by default (#878) by @​lcian
  • If the logs feature flag is enabled, and enable_logs: true is set on your client options, the default Sentry tracing layer now sends logs for all events at or above INFO.

Features

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian

  • Additional special fields have been added that allow overriding certain data on the Sentry span:
    • sentry.op: override the Sentry span op.
    • sentry.name: override the Sentry span name.
    • sentry.trace: given a string matching a valid sentry-trace header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid sentry-trace header or a trace is already started, this value is ignored.
  • sentry.op and sentry.name can also be applied retroactively by declaring fields with value tracing::field::Empty and then recorded using tracing::Span::record.
  • Example usage:

    #[tracing::instrument(skip_all, fields(
        sentry.op = "http.server",
        sentry.name = "GET /payments",
        sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()),
    ))]
    async fn handle_request(headers: std::collections::HashMap<String, String>) {
        // ...
    }

  • Additional attributes are sent along with each span by default:
    • sentry.tracing.target: corresponds to the tracing span's metadata.target()
    • code.module.name, code.file.path, code.line.number

• feat(core): add Response context (#874) by @​lcian

  • The Response context can now be attached to events, to include information about HTTP responses such as headers, cookies and status code.

... (truncated)

Sourced from sentry-actix's changelog.

0.43.0

Breaking changes

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian
  • The tracing integration now uses the tracing span name as the Sentry span name by default.
  • Before this change, the span name would be set based on the tracing span target (<module>::<function> when using the tracing::instrument macro).
  • The tracing integration now uses <span target>::<span name> as the default Sentry span op (i.e. <module>::<function> when using tracing::instrument).
  • Before this change, the span op would be set based on the tracing span name.
  • Read below to learn how to customize the span name and op.
  • When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
• ref(tracing): use standard code attributes (#899) by @​lcian
  • Logs now carry the attributes code.module.name, code.file.path and code.line.number standardized in OTEL to surface the respective information, in contrast with the previously sent tracing.module_path, tracing.file and tracing.line.
• fix(actix): capture only server errors (#877) by @​lcian
  • The Actix integration now properly honors the capture_server_errors option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).
  • Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
  • With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
  • There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
• fix: send trace origin correctly (#906) by @​lcian
  • TraceContext now has an additional field origin, used to report which integration created a transaction.

Behavioral changes

• feat(tracing): send both breadcrumbs and logs by default (#878) by @​lcian
  • If the logs feature flag is enabled, and enable_logs: true is set on your client options, the default Sentry tracing layer now sends logs for all events at or above INFO.

Features

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian

  • Additional special fields have been added that allow overriding certain data on the Sentry span:
    • sentry.op: override the Sentry span op.
    • sentry.name: override the Sentry span name.
    • sentry.trace: given a string matching a valid sentry-trace header (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a valid sentry-trace header or a trace is already started, this value is ignored.
  • sentry.op and sentry.name can also be applied retroactively by declaring fields with value tracing::field::Empty and then recorded using tracing::Span::record.
  • Example usage:

    #[tracing::instrument(skip_all, fields(
        sentry.op = "http.server",
        sentry.name = "GET /payments",
        sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()),
    ))]
    async fn handle_request(headers: std::collections::HashMap<String, String>) {
        // ...
    }

  • Additional attributes are sent along with each span by default:
    • sentry.tracing.target: corresponds to the tracing span's metadata.target()
    • code.module.name, code.file.path, code.line.number

• feat(core): add Response context (#874) by @​lcian

... (truncated)

• b08b24a release: 0.43.0
• 1c08ca8 ref(tracing): keep old span name as op instead of default (#905)
• 75aff83 fix(tracing): skip default span attributes when propagating to event (#904)
• 6b61b31 fix: send trace origin correctly (#906)
• 75a8c03 ref(tracing): use standard code attributes (#899)
• bbd667a meta: add pull request template (#898)
• 5c8ab31 ref(tracing): rework tracing to Sentry span name/op conversion (#887)
• 045c2e2 feat(tracing): send both breadcrumbs and logs by default (#878)
• a5932c0 fix(transport): add rate limit for logs (#894)
• 280dab9 build(deps): bump tracing-subscriber from 0.3.19 to 0.3.20 (#891)
• Additional commits viewable in compare view

Sourced from serde's releases.

v1.0.228

• Allow building documentation with RUSTDOCFLAGS='--cfg=docsrs' set for the whole dependency graph (#2995)

v1.0.227

• Documentation improvements (#2991)

• a866b33 Release 1.0.228
• 5adc9e8 Merge pull request #2995 from dtolnay/rustdocflags
• ab58178 Workaround for RUSTDOCFLAGS='--cfg=docsrs'
• 415d9fc Release 1.0.227
• 7c58427 Merge pull request #2991 from dtolnay/inlinecoredoc
• 9d3410e Merge pull request #2992 from dtolnay/inplaceseed
• 2fb6748 Remove InPlaceSeed public re-export
• f8137c7 Inline serde_core into serde in docsrs mode
• b7dbf7e Merge pull request #2990 from dtolnay/integer128
• 7c83691 No longer macro_use integer128 module
• Additional commits viewable in compare view

Sourced from serde_derive's releases.

v1.0.228

• Allow building documentation with RUSTDOCFLAGS='--cfg=docsrs' set for the whole dependency graph (#2995)

v1.0.227

• Documentation improvements (#2991)

• a866b33 Release 1.0.228
• 5adc9e8 Merge pull request #2995 from dtolnay/rustdocflags
• ab58178 Workaround for RUSTDOCFLAGS='--cfg=docsrs'
• 415d9fc Release 1.0.227
• 7c58427 Merge pull request #2991 from dtolnay/inlinecoredoc
• 9d3410e Merge pull request #2992 from dtolnay/inplaceseed
• 2fb6748 Remove InPlaceSeed public re-export
• f8137c7 Inline serde_core into serde in docsrs mode
• b7dbf7e Merge pull request #2990 from dtolnay/integer128
• 7c83691 No longer macro_use integer128 module
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions